Methods and apparatus for automated edge device configuration in a heterogeneous network

ABSTRACT

A PE device learns the address of a local CE device by monitoring the control messages, such as address resolution messages, originating from those local devices. In one embodiment, automated configuration of the PE devices participating in a Layer 2 VPN is facilitated by permitting a PE device to share the addresses for its locally-attached CE devices with the remote PE devices in the VPN. A PE device may share the addresses of the remote CE devices with the local CE devices by initiating its own control message or responding to an control message issued by one of its local CE devices. This latter mechanism in effect hides the distributed, heterogeneous nature of the network from a local CE device.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of the co-pending applicationhaving Attorney Docket No. TEN-008, filed herewith, the entiredisclosure of which is incorporated by reference as if set forth in itsentirety herein.

FIELD OF THE INVENTION

The invention relates generally to the interworking of customer edgedevices in a heterogeneous network and, in particular, to methods andapparatus that assist or automatically configure the provider edgedevices in that network.

BACKGROUND OF THE INVENTION

One application for multi-protocol label switching (MPLS) is theimplementation of Layer 2 virtual private networks (VPN) using MPLStunneling. Referring to FIG. 1, a typical wide area network (WAN)includes customer edge (CE) devices 100, 104, 108, and 112, and provideredge (PE) devices 116, 120 and 124. In general, an edge device is adevice, e.g., a router, that sits on the edge of a network cloud such asthe Internet or a private network. The customer edge devices connect acustomer to a provider network using a data link technology, such asframe relay, while the provider edge devices reside on the edge of theprovider network and aggregate connections from the customer sites. Inmany traditional configurations, the CE “devices” 100, 104, 108, and 112are actually groups of homogeneous CE devices—i.e., multiple CE devicesthat are connected to their PE device using the same data link or datalink type—that share the same edge of their connected PE device.

Each CE device 100, 104, 108, and 112 communicates with its connected PEdevice 116, 120, and 124 using a data link 128, 132, 136, or 144. In theillustrated network, data link 128 is a gigabit Ethernet data linkconnecting CE device 100 to PE device 116, data link 144 is a gigabitEthernet data link connecting CE device 112 to PE device 116, data link132 is an ATM data link connecting CE device 104 to PE device 120, anddata link 136 is a frame relay data link connecting CE device 108 to PEdevice 124. The WAN of FIG. 1 is a heterogeneous network in that the CEdevices in the WAN communicate with their associated PE devices usingdifferent data link layer protocols.

Each CE device may be said to be “local” to the PE device it is attachedto, and “remote” to the other PE devices in the WAN. For example, CEdevices 100 and 112 are local to PE device 116 and remote to PE devices120 and 124. Similarly, CE device 104 is local to PE device 120 andremote to PE devices 116 and 124.

The PE devices 116, 120, and 124 may communicate with each other througha network cloud 140 using various methods based on Border GatewayProtocol (BGP), Label Distribution Protocol (LDP), Layer 2 TunnelingProtocol (L2TP), etc. For example, using BGP through the cloud 140, thePE devices 116, 120, and 124 may exchange information that describes theblocks of Layer 2 virtual circuits connected to each PE device. Afterthis exchange of information and/or through configuration, each PEdevice is aware of the CE devices that belong to its own virtual privatenetwork (VPN) and the identifiers for the data links that connect thoseCE devices.

In operation, for example, when CE device 100 transmits information toCE device 104 across their VPN, CE device 100 first transmits its frameof information to its connected PE device 116. The PE device 116 readsthe Layer 2 header in the frame to identify the destination CE device104. The PE device 116 removes the Layer 2 header from the frame andconcatenates the raw IP packet with a VPN label that identifies thedestination CE device 104 and its associated PE device, i.e., PE device120. Then, the PE device 116 transmits the data using an MPLS tunnelthrough the network cloud 140 to the destination CE device's attached PEdevice 120. The PE device 120 receives this information and removes theVPN identifier from the packet. The PE device 120 prepends a Layer 2header that identifies the destination CE device 104 to the packetbefore transmitting it to the destination CE device 104 over the datalink 132.

This MPLS-based Layer 2 VPN is scalable, in that a new CE device may beadded to the WAN by physically connecting the CE device to an existingPE device, and then manually reconfiguring the PE device. However, itfails to provide a mechanism whereby the PE device would automaticallyconfigure itself and its peer PE devices to add the new CE device to thenetwork. Such a mechanism is desirable in that it reduces the amount ofhuman intervention required to add a new CE device to the network.Moreover, this VPN does not provide a mechanism for satisfying controlmessages, such as address resolution messages (e.g., an ARP request),sent from one CE device using one type of data link (e.g., a frame relaylink) that is attempting to discover the address of a second CE deviceacross the VPN that uses a different type of data link (e.g., an ATMlink).

SUMMARY OF THE INVENTION

The present invention relates to methods and apparatus that permit a PEdevice to learn the address of a local CE device by monitoring thecontrol messages, such as address resolution messages, originating fromthose local CE devices. In one embodiment, the invention facilitates theautomated configuration of the PE devices participating in a Layer 2 VPNby permitting a PE device to share the addresses for itslocally-attached CE devices with the remote PE devices in the VPN. Inaccordance with this embodiment, a PE device may share the addresses ofthe remote CE devices with the local CE devices by initiating its owncontrol messages or responding to a control message issued by one of itslocal CE devices. This latter mechanism in effect hides the distributed,heterogeneous nature of the network from a local CE device.

In one aspect, therefore, the present invention provides a method ofresolving network addresses between network devices on a heterogeneousnetwork in a device bridging data link layer protocols and network layerprotocols. Information concerning a first device in communication with afirst data link is gathered from a control message, such as an addressresolution message. Packets are received from a second device incommunication with a second data link, the first and second data linksutilizing different data link layer protocols. The gathered informationis provided to a third device in communication with the second devicethrough the second data link, e.g., by transmitting an MP-BGP NLRImessage to the third device. The packets are transmitted to the firstdevice using the gathered information concerning the first device. Thestep of transmitting the packets may include prepending a headeridentifying the second device to a received packet. Optionally,information may be received from the third device concerning a fourthdevice and this received information may be provided to the firstdevice, for example, by responding to a control message or initiating acontrol message.

The gathered information may be the first device's IP address, circuitinformation, a VC or VPN MPLS label, or the IP address for the seconddevice associated with that label. The data links may utilize, forexample, gigabit Ethernet, frame relay, point-to-point protocol (PPP),asynchronous transfer mode (ATM), or high-level data link controlprotocol (HDLC). Accordingly, depending on the type of data link, thecontrol message may be, respectively, an RDP message, an IARP message,an IPCP message, or an INATMARP message. In one embodiment, messageresponses may be generated using a placeholder value. In anotherembodiment, the NLRI message includes an IP address sub-TLV.

In another aspect, the present invention provides a system that resolvesnetwork addresses between network devices on a heterogeneous network.The system includes a first device bridging data link layer protocolsand network layer protocols and a second device in communication withthe first device using a first data link. A third device bridging datalink layer protocols and network layer protocols is in communicationwith a fourth device using a second data link. The second data link usesa different data link layer protocol from the first data link.

The first device gathers information concerning the second device fromcontrol messages—such as address resolution messages—sent by the seconddevice and provides the gathered information to the third device. Thethird device may utilize the information from the first device to routepackets from the fourth device to the second device. Suitable data linksinclude gigabit Ethernet data links, frame relay data links, PPP datalinks, ATM data links, and HDLC data links.

The foregoing and other features and advantages of the present inventionwill be made more apparent from the description, drawings, and claimsthat follow.

BRIEF DESCRIPTION OF THE DRAWINGS

The advantages of the invention may be better understood by referring tothe following description taken in conjunction with the accompanyingdrawings in which:

FIG. 1 depicts a WAN having CE devices connected locally to theirrespective PE devices and remotely to other PE devices through a networkcloud; and

FIG. 2 is a flowchart illustrating one embodiment of a method for theautomatic configuration of the PE devices of FIG. 1.

In the drawings, like reference characters generally refer tocorresponding parts throughout the different views. The drawings are notnecessarily to scale, emphasis instead being placed on the principlesand concepts of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In brief overview, the present invention permits a PE device in aheterogeneous network to learn the address information for itslocally-connected CE devices by monitoring the control messages sent bythe CE devices. In one embodiment, the PE device then shares thislearned address information with other PE devices. These remote PEdevices may then provide their own locally-connected CE devices with theshared address information they have received. Using this information,the PE devices transparently route communications between CE devicesthat are connected to their PE devices using different types of datalinks.

As discussed above, one or more PE devices 116, 120, and 124 in theheterogeneous WAN of FIG. 1 participate in IP interworking by changingthe Layer 2 encapsulation of the IP protocol data units (PDUs) flowingto and from the CE devices that are local to it. Referring to FIG. 2,the PE devices gather information concerning their locally-connected CEdevices by monitoring the control messages sent by the CE devices (Step200). Once this information is gathered, each PE device may share theinformation concerning its locally-connected CE devices with the otherPE devices in the network using a PE protocol such as BGP, LDP, L2TP,etc. (Step 204). With the receipt of this shared information, a PEdevice in the VPN has address information concerning both its ownlocally-connected CE devices and those CE devices that are remote to it,but local to another PE device in the VPN. The PE device may now sharethe information concerning the remote CE devices with itslocally-connected CE devices, either directly or indirectly (Step 208).Using the exchanged address information, the PE device may nowparticipate in interworking as described above (Step 212).

In one embodiment, the control messages from the local CE devices (Step200) are address resolution messages, as discussed in detail below. Theinformation gathered from the control messages may include, but is notlimited to, one or more of a local CE device's IP address, circuitinformation, a virtual channel (VC) or VPN MPLS label, or the IP addressfor the remote CE associated with that label. Once gathered, thisinformation may be stored as a tuple or other data structure in avolatile memory, such as a random-access memory (RAM), and/or anonvolatile memory, such as a hard disk. In a Layer 2 interworking VPNthere is typically one tuple for each circuit that the CE device hasattached to its local PE device. Although the process for gatheringinformation (Step 200) varies among the various types of data linksconnecting CE devices to their local PE devices, it typically includesthe receipt of a control message from a local CE device, the extractionof information concerning the local CE device from the control messageand, optionally, the storage of this information in a volatile or anon-volatile memory.

Gathering Local CE Device Information

When the data link is a gigabit Ethernet data link, e.g., data link 128,the PE device may learn the address of a local CE device (Step 200) on agiven Ethernet circuit using router discovery protocol (RDP), as setforth in IETF RFC 1256 and incorporated by reference as if set forthfully herein. If the PE device is connected to the local CE device usinggigabit Ethernet with virtual local-area network (VLAN) tagging (asdescribed in IEEE standard 802.1Q and incorporated by reference as ifset forth fully herein), then the VLAN tag may represent an IP subnetand the circuit information will then consist of Ethernet interfaceinformation and the VLAN tag. If the PE device does not use IEEE 802.1QVLAN tagging, then the entire Ethernet port is treated as a singleendpoint that is connected to one remote endpoint through a pair of PEdevices, the Ethernet interface is the IP subnet, and the circuitinformation only includes Ethernet interface information. Regardless ofwhether the PE device supports IEEE 802.1Q tagging, only one CEdevice—in this case the Ethernet router end station—is presumed toparticipate within the IP interworking-based Layer 2 VPN.

When the data link is a frame relay data link, e.g., data link 136, anewly-attached CE device may generate an inverse address resolutionprotocol (IARP) request—defined in IETF RFC 2390 and incorporated byreference as if set forth in its entirety herein—to obtain the IPaddresses of its neighboring devices when the data link connectionidentifier (DLCI) associated with the IP interface becomes active.Typically, the DLCI will become active when the local PE device haslearned cross-connect-related information from a remote PE device usingBGP, presenting a stalemate problem that may be resolved as discussedbelow. Once the local CE device issues the IARP request, the attached PEdevice may determine the local CE device's IP address and DLCIinformation from the IARP request (Step 200).

When the data link uses point-to-point protocol (PPP), then the attachedCE device participates in internet protocol control protocol (IPCP,defined in IETF RFC 1332 and incorporated by reference as if set forthin its entirety herein) to obtain the IP addresses for its neighbordevices. By examining the local CE device's IPCP request, the PE devicemay determine the CE device's IP address (Step 200).

When the data link is an asynchronous transfer mode (ATM) link, anattached CE device treats each virtual circuit (VC) as an IP subnet. Theattached CE device may participate in inverse ATM ARP (INATMARP, definedin IETF RFC 1577 and incorporated by reference as if set forth in itsentirety herein) to obtain the IP addresses for its neighbor devices.The PE device may learn the local CE device's IP address from the localCE device's INATMARP request (Step 200).

The high-level data link control protocol (HDLC, described in ISOStandard 3309 and incorporated by reference as if set forth in itsentirety herein) does not specify a protocol mechanism for obtaining theIP address of a neighboring device. Instead, a device using HDLCreceives IP data frames from a single remote endpoint and, therefore,implicitly assumes the presence of a single IP address. Therefore, whenthe data link connecting the PE device to its local CE device is an HDLCdata link, the PE device is manually configured with the IP address ofthe local CE device to permit the local PE device to distributecross-connect information to remote PE devices (Step 200).

Sharing Remote CE Device Information with Remote PE Device

Having gathered information from the control messages, such as addressresolution messages, sent by the local CE devices (Step 200), a PEdevice may now share information concerning its local CE devices withanother PE device (Step 204). These cross-connect advertisements mayinclude, for example, one or more of the local CE device's IP address,circuit information, a virtual channel (VC) or VPN MPLS label, or the IPaddress for the remote CE associated with that label. In variousembodiments of the invention, the PE devices may communicate usingBorder Gateway Protocol (BGP), Label Distribution Protocol (LDP), Layer2 Tunneling Protocol (L2TP), etc.

In one embodiment, the information may be sent to a PE device at theedge of the network cloud using multiprotocol BGP (MP-BGP) network layerreachability information (NLRI) messages. A typical NLRI messageincludes a label block offset, a label base, and a length of the circuitstatus vector sub-TLV. The NLRI messages sent to the remote PE deviceprovide a set of contiguous labels starting from the label base valuethat correspond to a set of remote CE identifiers starting from thelabel block offset.

In accord with the present invention, the NLRI message may also includea second sub-TLV of type TBD that contains an IP address. A PE deviceadvertises this new IP address sub-TLV when the VPN's encapsulation typeis IP interworking. This second sub-TLV has the same length as thecircuit status vector sub-TLV. The length field of the sub-TLV specifiesthe number of 4-byte fields contained in the value field of the IPaddress sub-TLV, where each field is an IP address that has a one-to-onecorrespondence with the labels represented by the label base and lengthfield. By iterating through each IP field value in order, a receiving PEdevice may determine the association between a label and an IP address.

Sharing Remote CE Device Information with Local CE Device

Once a PE device has received these cross-connect advertisements, e.g.,an IP address-to-label association, the PE device may provide thisinformation to its local CE devices (Step 208). Although the process forsharing the information (Step 208) varies depending on the type of datalink between the local CE devices and their PE devices, the process istypically either active, e.g., the PE device transmits an controlmessage to its local CE devices, or passive, e.g., the PE deviceresponds to its local CE device's control message with the remote CEdevice's address information.

When the data link is a gigabit Ethernet data link, the PE device maygenerate an address resolution protocol request (ARP, defined in IETFRFC 826 and incorporated by reference as if set forth in its entiretyherein) to present the IP address of the remote CE device as a neighborto the local CE device (Step 208). If the PE device supports IEEE 802.1Qtagging, then the request must be generated within the VLAN scope. ThePE device may also respond to the local CE device's ARP request with itsown MAC address as the target hardware address when the WAN IP addressof the cross-connected remote CE device is known (Step 208). To makecommunications with the remote CE device transparent, the local PEdevice may optionally provide its MAC address in the source hardwareaddress field of the ARP request and the target hardware address fieldof the ARP reply. If two CE devices are locally attached to their PEdevice on gigabit Ethernet data links, then the local PE device maypropagate an ARP request or an ARP response with VLAN tag translationdirectly to the second CE device.

When the data link is a frame relay data link and the PE device hasreceived cross-connect information from a remote PE device, then thecorresponding DLCI at the local PE device is inactive. The local PEdevice may initiate an IARP request providing the address informationfor the cross-connected remote CE device, or it may wait for theattached CE device to generate an IARP request and then respond with theaddress information (Step 208).

When the data link uses PPP, the PE device may respond to IPCP requestsfrom its local CE devices with the IP address information for the remoteCE devices when that information becomes available (Step 208). If the IPaddress information and the cross-connect information are available, thePE device may also initiate an IPCP request to provide the local CEdevice with address information for the cross-connected remote CEdevices (Step 208).

When the data link is an ATM data link, the PE device may generate anINATMARP message for its local CE devices when the address informationfor the remote cross-connected CE devices becomes available. If thelocal PE device has received the cross-connect information and theassociated IP address information from a remote PE device, then thelocal PE device may optionally respond to an INATMARP request receivedfrom its local CE devices (Step 208).

As discussed above, the address information for a remote CE device maynot be available to a particular PE device when that PE device receivesa control message, such as an address resolution message; from its localCE device. In that event; if the remote CE device's information is notavailable, then the PE device may advertise the cross-connectinformation to its local CE devices without the remote CE device'saddress by using a dummy value (such as zero) in the new IP addresssub-TLV (Step 208). When the address information for the remote CEdevice becomes available, the PE device may generate a new advertisementto its local CE devices with an updated IP address field value (Step208). This behavior prevents a stalemate situation, e.g., in a framerelay data link, where the local CE device will not transmit a controlmessage that will eventually be conveyed as cross-connect informationuntil its attached PE device signals its readiness, and the attached PEdevice will not signal its readiness until it receives cross-connectinformation that originates with a remote CE device that is waiting forits own PE device to signal its readiness.

Many alterations and modifications may be made without departing fromthe spirit and scope of the invention. Therefore, it is to be understoodthat these embodiments have been shown by way of example and should notbe taken as limiting the invention, which is defined by the followingclaims. These claims are thus to be read as not only including literallywhat is set forth by the claims but also to include those equivalentswhich are insubstantially different, even though not identical in otherrespects to what is shown and described in the above illustrations.

1. In a device bridging data link layer protocols and network layer protocols, a method of resolving network addresses between network devices on a heterogeneous network, the method comprising: gathering information from a control message concerning a first device in communication with a first data link; receiving packets from a second device in communication with a second data link, the first and second data links using different data link layer protocols; providing the gathered information to a third device, the third device in communication with the second device through the second data link; and transmitting the packets to the first device using the gathered information concerning the first device. 2-28. (canceled) 